Remarks 

Claims 1-31 are currently pending in the present application. Claims 1 and 18 are 
independent claims, which have been amended herein for clarification. Claims 20, 2 1 , 25, 27-29 and 
3 1 have also been amended for clarification. Minor amendments to the specification have also been 
made to correct minor errors. All claims have been rejected in the Office Action dated March 24, 
2004. Applicant traverses each of these rejections as discussed in detail below. 



Rejections Under 35 USC. §102 

The Office Action rejects claims 1-10, 16-28, 30 and 31 under 35 U.S.C. §102(e) as being 

anticipated by US Patent No. 6,487,600 to Lynch. ("Lynch"). However, as will be discussed in 

greater detail below, Lynch does not anticipate claim 1 because, among other things, Lynch does not 

disclose connecting remote clients "as if they were connected to a LAN". Li the claimed invention, a 

LAN-like virtual network is established using a "virtual network generation (VNG) system that is 

also not anticipated by Lynch. To clarify, in accordance with the present invention: 

A PNC is, preferably, setup and controlled automatically, 
dynamically and remotely by a PNC control system, which has the 
ability to route through public networks in a manner that enables 
substantially similar security and functionality available in 
traditional private networks, such as a LAN . From the perspective of 
the end-user at a client, the nature of the physical network through 
which information is routed is irrelevant. The PNC appears to the 
end-user as a traditional, dedicated private network that emulates a 
natural familiar and standard LAN workflow . 

(Application, p. 5 lines 9-15, emphasis added) 

Lynch does not disclose such a network. Rather, Lynch discloses dynamic manifest network 
where network members can communicate - but there is no suggestions that this network is LAN- 
like to enable "standard LAN workflow". For example, the Abstract of Lynch discloses: 

A dynamically configured user network services a plurality of 
network members. A metanetwork definition identifies the members 
of the dynamic manifest network and provides the rules by which the 
network members establish links among themselves and 
communicate. Each of the network members employs a client 
communication device to communicate with another network member 
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according to the metanetwork definition. Another centrally located 
computer, a network friend , may assist in setting upon and managing 
the dynamic manifest network via creating and altering the 
metanetwork definition . . . . The network friend has the basic structure 
of a web server ... A metanetwork definition is setup by an initiating 
network member. The metanetwork definition defines the dynamic 
manifest network and how communications will occur within the 
dynamic manifest network. A local view of the metanetwork is then 
created for each network member. A respective local view of the 
metanetwork is then provided to each network member. Each network 
member then establishes links with other network members and 
communicates with the other network members according to the local 
view. (Lynch, Abstract, emphasis added) 

As will be apparent from review of individual elements of claim 1 and various components of 
Lynch, the structural differences between the two make Lynch incapable of providing a LAN-like 
PNC as provided in claim 1. To better clarify the present invention various elements will be 
specifically discussed and contrasted to Lynch. 

With respect to claim 1 , element A , the office action asserts that "virtual network generation 
(VNG) system" of this element is anticipated by the "network friend" of Lynch, and that the "PNC 
attributes, including ... client attributes and ... network attributes" are anticipated by the 
"metanetwork definition" stored at the network friend. 

According to Lynch, the metadefinition accomplishes 2 basic functions: a) "identifies 
members of the dynamic manifest network" and b) "provides the rules by which the network 
members communicate". Lynch states that the network friend "may assist ... by creating and 
altering the metanetwork definition", where the "[mjanagement functions include receiving feedback 
from dynamic manifest members and using the feedback to modify the metanetwork definition." 
(Lynch, col. 3 line 55 -col. 4 line 3, see also, col. 6 lines 12-50) However, the VNG system of the 
claim does not use feedback from clients to modify the PNC attributes - i.e., the VNG system does 
not change the PNC attributes that were initially defined by a user. 

Another significant, and perhaps more fundamental, departure from of Lynch's network 
friend from the VNG system of this claim can be appreciated with the following text from Lynch: 
Link formation and subsequent communications among network 
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members of a dynamic manifest network are accomplished directly 
from network member to network member without direct intervention 
of the network friend 102 . However, the network friend 102 (in the 
described embodiment) does define the potential link structure of 
each dynamic manifest network and keeps track of such potential link 
structure(s) in the metanetwork configuration 104. Thus, when a 
network member initially joins a metanetwork, a local view of the 
dynamic manifest network that the network member joins is created 
from the metanetwork. The local view of the dynamic manifest 
network is then downloaded to the network member (or distributed 
via computer readable medium) to apprise the network member of the 
structure and communication rules for the dynamic manifest network. 
Subsequently, the network member establishes links with, and then 
communicates, with other network members of the dynamic manifest 
network according to the structure and communication rules. In 
another embodiment, however, the definition of the metanetwork is a 
collection of local views created and maintained by the network 
members. In such a structure, the network friend is not required . 

(Lynch, col. 6 line 51- col. 7, line 5, emphasis added ) 

Therefore, according to Lynch, the network friend is needed to provide the "local view" to 
each network member - but does not participate in the communication between the network 
members (or clients, in the case of claim 1). Regardless of the network friend's dynamic changing 
of the metanetwork definition using feedback, as mentioned above, the communication between 
network members in Lynch is direct, and not via the network friend. 

Claim 1, element A has been amended to clarify that the clients link to the VNG system. 
Element D has also been amended to clarify that the clients coordinate the communication link via 
the VNG system, the VNG system centrally controls that connection and that session communication 
between clients can either flow directly or via the VNG system as well, unlike Lynch where the 
network members communicate directly with each other and expressly not through the network 
friend - in fact, the network friend is not even required. Because the clients in claim 1 connect to 
the VNG system, and the VNG system (as provided in the first quote above) "has the ability to route 
through public networks in a manner that enables substantially similar security and functionality 
available in traditional private networks, such as a LAN", the VNG system can create the LAN-like 
network. But in Lynch, communication is directly between the network members, without the 
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network friend, so the network friend, important contrast to the VNG system, can not create a LAN- 
like environment. For the foregoing reasons, Applicant contends that the VNG system of claim 1 is 
not anticipated by the network friend of Lynch. 

With respect to element B, Lynch does not disclose a "VNG system data store including 
PNC information related to said plurality of clients and a plurality of network types". With respect 
to this element, the office action stated that "the network friend contains information about the 
clients and metanetwork." Yet, FIG. 2 of Lynch (indirectly referenced by the office action) shows 
that in step 166 the user must "enter known member informfation]", which is sent to the network 
friend in step 168. The result, therefore, is that the network friend does not in fact, possess client 
information in a data store - but rather needs it provided from a network member . Further, as is 
clear in the Abstract of Lynch, the network friend also does not access a data store for network 
attributes, but also needs that provided by a user. Without that information being provided by a 
network member, the network friend could not, in step 172, create the metanetwork definition. 
Lynch teaches away from element B, which claims accessing an existing data store of client and 
network information. 

With respect to element C the office action states that "authenticating", as provided by this 

element, is also anticipated by Lynch. But, in fact, upon closer review Lynch and the present 

invention authenticate much differently. That is, Lynch discloses authentication to be between 

network members , as follows: 

Further, authentication rules are set in place so that, prior to the 
exchange of a communication between network members across a 
link (two network members) the network members authenticate each 
other . Further, once the network members have authenticated each 
other, encryption/decryption rules may be enacted to further secure 
the communications across the link. 

(Lynch, col. 4 lines 36-39, emphasis added) 

However, in the present invention, clients authenticate with the VNG system, as a 
prerequisite to entering the PNC (private network community). For example, as provided in the 
Summary of Invention of the present application: 

The core functionality hosted by the VNG server(s) may include 
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several modules necessary for establishing and managing each PNC, 
authenticating users . . . 

(Application, p. 7 lines 14-15) 

A user may be required to initially register and subsequently 
authenticate, via the Web interface, with the VNG system prior to 
being enabled to create or join a PNC. 

(Application, p. 8 lines 19-21) 

See also flowchart 600 of FIG. 6 and the registration and authentication manager 342 of FIG. 
7, and the respective text in the specification of the present application. Since in Lynch the network 
members do not authenticate with the network friend, but rather with each other, Lynch does not 
anticipate the "authenticating" step of this element of claim 1. 

With respect to element D of claim 1 , the office action states that "establishing a PNC . . ." is 
anticipated by "directly connecting clients after establishing a group" as disclosed in Lynch. As 
mentioned above, this element of claim 1 has been amended to clarify that communication in the 
present invention among the clients is initiated, coordinated and controlled via the VNG system. 
This amendments is supported through the specification, where the roles and components of the 
VNG system are detailed, (e.g., Application, p. 5 first paragraph; p. 33 first paragraph and FIG. 8A- 
C) No direct client-to-client instantiation is allowed, without the VNG system. Only when the VNG 
system control channel is in place may the client assume session communication in which the data 
may either flow directly or via the VNG system. As also shown above, Lynch explicitly discloses 
direct communication between network members, which clearly does not take place via the network 
friend, which is not even required. That is, the VNG system is part of the communication in the 
present invention, and in doing so enables the LAN-like communication. Lynch does not anticipate 
this, and structurally and functionally teaches away from this type of network. 

For all of the foregoing reasons, Lynch does not anticipate claim 1. The Applicant 
respectfully requests removal of this rejection. 

For the same reasons, Applicant asserts that Lynch does not anticipate those claims that 
depend from claim 1 and rejected under this section of the patent statute. Accordingly, the Applicant 
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further requests removal of the rejections to claims 2-10, 16, and 17, which depend from claim 1 . 

Claim 18 is an apparatus claim that corresponds to method claim 1. Accordingly, claim 18 
has been amended in a manner similar to that of claim 1 . Therefore, for the same reasons put forth 
with respect to claim 1, the Applicant asserts that claim 18 is not anticipated by Lynch. Applicant 
respectfully requests removal of the rejection to claim 1 8 and its dependent claims 1 9-28, 30, and 3 1 . 

Rejections Under 35 USC §103 

The Office Action rejects claims 11-15 and 29 under 35 U.S.C. §103 (a) as being unpatentable 
over US Patent No. 6,487,600 to Lynch ("Lynch") in view of US Patent No. 6,427,07 1 to Adams et 
al. ("Adams et al") The office action acknowledges that Lynch does not anticipate or make obvious 
wrapping and unwrapping packets, but asserts that Adams does teach this. Generally, the Applicant 
asserts that there is no motivation to combine Lynch and Adams, since Adams discloses secure 
communication between "a controller and a signaling network" (see Abstract of Adams) and Lynch 
teaches establishing communication between two network members (as peers). Nevertheless, 
assuming the combination, the Applicant believes the two references do not make obvious claims 11- 
15 and 29. 

Claims 11-15 depend from claim 1, discussed in detail above with respect to Lynch. 
Therefore, Applicant believes that, like independent claim 1 , dependent claims 1 1 - 1 5 are patentable 
over Lynch, even if combined with Adams. Accordingly, Applicant respectfully requests removal of 
the rejections to claims 11-15. 

Claim 29 depends from claim 1 8, discussed in detail above with respect to Lynch. Therefore, 
Applicant believes that, like independent claim 18, dependent claim 29 is patentable over Lynch, 
even if combined with Adams. Accordingly, Applicant respectfully requests removal of the 
rejections to claim 29. 

The Applicant respectfully request removal of the foregoing rejections and allowance of 
pending claims 1 -3 1 , as variously amended herein. The Commissioner is hereby authorized to 
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charge any additional fees under 37 C.F.R. §1.16 and §1.17 that maybe required, or credit 
any overpayment, to our Deposit Account No. 50-1 133. 



Respectfully submitted, 




David M. Mello, Reg. No. 43,799 
McDermott Will & Emery LLP 
28 State Street 
Boston, MA 02109 
Tel.: (61 7) 535-4037 
Facsimile: (617) 535-3800 



Date: September 8. 2004 



E-mail: dmello@mwe.com 
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